REMARKS 

Claims 1-53 are pending. Claims 1-16, 34-43, 52, and 53 are withdrawn from 
consideration. Claims 1-53 have been subjected to a restriction requirement. Claims 17-33 and 
44 to 51 stand rejected under 35 U.S.C. §101 as being directed to non-statutory algorithm type 
subject matter. Claims 17-23, 25-3 1 and 44-50 stand rejected under 35 U.S.C. § 102(b) as being 
anticipated by Ramakrishnan (1998). Claim 24 stands rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Ramakrishnan as applied to claims 17-23, 25-31 and 44-50 above, and further 
in view of Silberschatz (1996). 

Reconsideration is requested. The rejections are traversed. No new matter is added. The 
specification has been amended to correct typographical errors. Claims 17, 26, and 44 are 
amended. Claims 25 and 47 are canceled. Claims 54-71 have been added. Claims 17-24, 26-33, 
44-46, 48-51, and 54-71 remain in the case for consideration. 

REJECTION UNDER 35 U.S.C. §101 

Claims 17-33 stand rejected as being directed to non-statutory algorithm type subject 
matter. The Examiner says that claims 17-33 "are directed to a method comprising steps for 
manipulating objects (data) without any physical alteration step, which is considered to be non- 
statutory subject matter. The instant specification (page 3, lines 25-26 discloses an 'object is a 
"thing" represented in a computer;' which has been interpreted as a modeling process. 'For 
example, a computer process that simply calculates a mathematical algorithm that models noise 
is non-statutory. However, a claimed process for digitally filtering noise employing the 
mathematical algorithm is statutory.' (MPEP § 2106(IV)(B)(2)(b), part ii). Similar to the 
nonstatutory example above, the instant invention comprises algorithmic steps for manipulating 
objects without any physical alteration resulted from said analysis or modeling steps." 

MPEP § 2106 IV.B.2(b), part ii) provides that a "claim is limited to a practical 
application when the method, as claimed, produces a concrete, tangible and useful result; i.e., the 
method recites a step or act of producing something that is concrete, tangible and useful." 

The Applicant has amended claim 17 to further recite "associating a first rule with the 
contract object the first rule including a first event that can occur to the first object and a first 
action; receiving the first event; accessing the first rule associated with the contract object; and 
updating at l east one of the contract object and the second object according to the first action 
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responsive to the first event." FIGs. 5A-5C of the present application show exemplary events 
and corresponding rules for updating at least one of the second object and the contract object if a 
particular event occurs to the first object. For example, page 7, lines 37-18 of the specification 
describes "rule 515, which indicates that when a rename event occurs to a file, the metadata 
stored in the contract is updated." Page 7, lines 28-30 of the specification says that "|w]hen 
move event 530 occurs, contract 215 accesses rule table 510, and finds rule 535, which says that 
when a file is moved from one collection to another, the contract changes the collection with 
which the contract is associated." On page 8, lines 3-5, delete event 545 and a corresponding 
rule are described. After a first object is deleted, the contract object is disassociated from the 
second object and then deleted. 

The Applicant believes that claim 17 produces a concrete, tangible and useful result. 
After receiving a first event that occurred to the first object, the rule associated with the contract 
object is accessed, and the contract object and/or the second object are updated according the 
action provided in the rule. This is not a passive model, but an active method for using a 
contract object to represent a relationship between two objects, even after events occur that can 
affect the relationship. By associating rules for responding to events with the contract object, 
when events occur for the first object, the system can actively update either the second object 
and/or the contract object according to the rule. The update is triggered by an event that occurs 
to an object. This is not merely modeling objects, but doing something concrete, tangible and 
useful to the objects in response to an event occurring. Accordingly, claim 17 is patentable 
under 35 U.S.C. §101, as are dependent claims 18-24, 26-33, 54-61, and 71. 

Claims 54-56 have been added to illustrate rules with events and actions that are 
associated with the contract object and used to update the contract object and/or the other object 
that did not have the event. Claim 54 recites receiving a rename event, claim 55 recites receiving 
a delete event, and claim 56 recites receiving a move event to move the first object from the 
second object to a third object. Each of these claims further recites an action in the rule for 
updating at least one of the contract object and the second object. For example, when a first 
object is renamed, the corresponding action recited in claim 54 is an update to a metadata item in 
the contract object. Claim 55 recites a disassociation of the contract object and a deletion of the 
contract object if the first object is deleted. Finally, if the first object is moved from the second 
object to a third object, claim 56 recites a removal of the association from the contract object to 
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the second object and an addition of an association from the third object to the contract object. 
Because claims 54-56 produce a concrete, tangible and useful result, claims 54-56 are patentable 
under 35 U.S.C. §101. 

The Examiner has rejected claims 44-51, saying that these claims are "directed to a 
computer-readable media comprising software for manipulating 'objects.'" In paragraph 1 1, on 
page 4 of the Office Action dated January 24, 2006, the Examiner has interpreted objects as 
"nonfunctional descriptive material as supported by the instant specification (page 3, lines 25- 
26). '[W]hen nonfunctional descriptive material is recorded on some computer-readable 
medium, it is not statutory since no requisite functionality is present to satisfy the practical 
application requirement. Merely claiming nonfunctional descriptive material stored in a 
computer-readable medium does not make it statutory. (MPEP §2106 (IV)(B)(1))." 

The Examiner says that the limitation of "objects" is nonfunctional descriptive material. 
But the Examiner does not address that claims 44-47 and 50-51 are not directed towards the 
objects themselves, but to computer-readable media containing a program that manipulates the 
objects. In fact, the Examiner mischaracterized claims 44-51 as nonfunctional descriptive 
material. Claims 44-51 are claims to computer programs, which the MPEP treats as functional 
descriptive material. MPEP §2106 IV.B.l provides that "descriptive material can be 
characterized as either 'functional descriptive material' or 'nonfunctional descriptive material.' 
In this context, 'functional descriptive material' consists of data structures and computer 
programs which impart functionality when employed as a computer component. . . . When 
functional descriptive material is recorded on some computer-readable medium it becomes 
structurally and functionally interrelated to the medium and will be statutory most cases since 
use of technology permits the function of the descriptive material to be realized." 

MPEP §2106 IV.B.l (a) further elaborates: "Since a computer program is merely a set of 
instructions capable of being executed by a computer, the computer program itself is not a 
process and Office personnel should treat a claim for a computer program, without the computer- 
readable medium needed to realize the computer program's functionality, as non-statutory 
functional descriptive material. When a computer program is claimed in a process where the 
computer is executing the computer program's instructions, Office personnel should treat the 
claim as a process claim. See MPEP § 2106 paragraph IV.B.2(b). When a computer program is 
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recited in conjunction with a physical structure, such as a computer memory, Office personnel 
should treat the claim as a product claim. See MPEP § 2106 paragraph IV.B.2(a)." In other 
words, when a claim recites a program on a computer-readable medium, the claim is statutory. 

Claims 44-46, 48-51, and 62-70 recite "[c]omputer-readable media containing a 
program." Page 12, lines 3-7 of the specification describes types of media as "floppy disks, 
optical discs (such as compact discs), or fixed disks (such as hard drives)" and that computer 
programs "can be resident in memory, such as random access memory (RAM), read-only 
memory (ROM), firmware, or flash RAM memory. The program as software can then be 
executed on a computer to implement the method." Thus, as claims 44-46, 48-51, and 62-70 are 
directed toward a computer program stored on a computer-readable media, claims 44-46, 48-5 1 , 
and 62-70 are patentable under 35 U.S.C. § 101. 

REJECTION UNDER 35 U.S.C. § 102(b) 

Referring to claim 17, the invention is directed towards a computer-implemented method 
for using a contract object, comprising: identifying a first object; identifying a second object; 
determining a relationship between the first object and the second object; using the contract 
object to represent the relationship between the first object and the second object; associating a 
first rule with the contract object the first rule including a first event that can occur to the first 
object and a first action; receiving the first event; accessing the first rule associated with the 
contract object; and updating at least one of the contract object and the second object according 
to the first action responsive to the first event. 

Referring to claim 44, the invention is directed towards computer-readable media 
containing a program to use a contract object, the program comprising: software to identify a 
first object; software to identify a second object; software to determine a relationship between 
the first object and the second object; software to use the contract object to represent the 
relationship between the first object and the second object; software to associate a first rule with 
the contract object, the first rule including a first event that can occur to the first object and a first 
action; software to receive the first event; software to access the first rule associated with the 
contract object; and software to update at least one of the contract object and the second object 
according to the first action responsive to the first event. 
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FIGs. 5A-5C of the present application show events and corresponding rules for updating 
at least one of the contract object and the second object if a particular event occurs to the first 
object. For example, page 7, lines 17-18 of the specification describes "rule 515, which indicates 
that when a rename event occurs to a file, the metadata stored in the contract is updated." Page 
7, lines 28-30 of the specification says that "[wjhen move event 530 occurs, contract 215 
accesses rule table 510, and finds rule 535, which says that when a file is moved from one 
collection to another, the contract changes the collection which the contract is associated." On 
page 8, lines 3-5 describes delete event 545 and the associated rule. After a first object is 
deleted, the contract is disassociated from the second object and then deleted. 

In contrast, Ramakrishnan teaches an introduction to database systems. In the first 
paragraph on page 359, Ramakrishnan teaches that an entity can be an object distinguishable 
from other objects, and that similar entities can be collected together. As used by Ramakrishnan, 
an entity can be thought of as a database table or record. On page 360, Ramakrishnan teaches 
that different entities can be associated to each other, forming a relationship or relationship set. 

FIG. 14.3 on page 361 of Ramakrishnan shows an example of two different entities, 
employees and departments. The Examiner cites to the entities in Ramakrishnan as teaching a 
first object and a second object. The employees and departments entities have a relationship of 
Works_In. For example, each employee works in a division. Ramakrishnan teaches on page 
363, that the relationship Works_In can be a table with information on an employee and the 
departm ent that the employee works in. An example create statement to create an instance of the 
Works_In table is shown on page 363 of Ramakrishnan. In the table there are fields for a 
primary key to identify the record in the Worksjm table. In addition, page 363 of Ramakrishnan 
also shows two foreign keys: a foreign key pointing to an employee record and a foreign key 
pointing to a department record. 

Section 2.2.1 on pages 26-28 of Ramakrishnan teaches key constraints. As provided on 
page 26 of Ramakrishnan, a "key constraint is a statement that a certain minimal subset of the 
fields of a relation is a unique identifier for a tuple." In footnote 3 on page 27, Ramakrishnan 
clarifies that when discussing keys in the contest of access methods, he is referring to search 
keys. 

The Examiner has indicated that a query as taught in section 2.2.1 of Ramakrishnan is 
being interpreted as an event. The Applicant does not see any discussion in pages 26-28 relating 



Docket No. 6647-049 



Page 19 of 29 



Application No. 10/626,097 



to queries; instead, Ramakrishnan describes therein key constraints that enable an object to have 
a unique identifier. 

But even if Ramakrishnan did teach a query, this would not be an event to a first object 
triggering an update to at least one of the second object and the contract object. Instead, a query 
is a purely passive event that simply returns a dataset matching the query: a query does not 
update any data. Referring to the Worksjn relationship on page 361 of Ramakrishnan, a 
possible query could be a list of employees that work in a particular department. The query 
would likely receive a department identifier, and then return a list of names and social security 
numbers of the employees in the particular department. But this is not updating data in the 
Works_In table, or updating data in either the employees table or the departments table. 

Further, the Examiner does not show any reference teaching a rule describing how an 
action can be taken to update the second object or the contract object in response to the event that 
occurred. For example, suppose an employee moved from one department to another 
department. This might arguably be like the file moving event as described above. According to 
claims 17 and 44, after the event has been received, the contract object for the file determines the 
rule describing how to update the contract object or the second object in response to the move 
file event. 

Ramakrishnan does not teach receiving an event to the first object, and then updating at 
least one of the contract object and the second object responsive to the first event. In fact, no 
such event is ever received in Ramakrishnan. Users can of course, manually change data in the 
tables. But a user manually changing data in Ramakrishnan does not trigger a change in other 
data. 

Because Ramakrishnan does not teach receiving a first event and updating at least one of 
the contract object and the second object according to a rule, claims 17 and 44 are patentable 
under 35 U.S.C. § 102(b) over Ramakrishnan. Accordingly, claims 17 and 44 are allowable, as 
are dependent claims 18-24, 26-33, 45-46, 48-51, and 54-71. 

Referring to claim 54, the invention is directed towards a computer-implemented method 
according to claim 17, wherein: the first event includes a rename event; and the first action 
includes an update to a metadata item for the first object in the contract object. 
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Referring to claim 55, the invention is directed towards a computer-implemented method 
according to claim 1 7, wherein: the first event includes a delete event; and the first action 
includes a disassociation of the contract object from the second object and a delete of the 
contract object. 

Referring to claim 56, the invention is directed towards a computer-implemented method 
according to claim 17, wherein: the first event includes a move event to move the first object 
from the second object to a third object; and the first action includes a remove of the association 
from the contract object to the second object and an add of an association from the third object to 
the contract object. 

Referring to claim 62, the invention is directed towards computer-readable media 
according to claim 44, wherein: the first event includes a rename event; and the first action 
includes an update of a metadata item for the first object in the contract object. 

Referring to claim 63, the invention is directed towards media according to claim 44, 
wherein: the first event includes a delete event; and the first action includes a disassociation of 
the contract object from the second object and a delete of the contract object. 

Referring to claim 64, the invention is directed towards computer-readable media 
according to claim 44, wherein: the first event includes a move event to move the first object 
from the second object to a third object; and the first action includes a remove of the association 
from the contract object to the second object and an add of an association from the third object to 
the contract object. 

As discussed previously with respect to the 35 U.S.C. § 101 rejection of claims 17-33, 
claims 54-56 and 62-64 illustrate types of events that can occur to the first object, and 
corresponding rules for updating the contract object and/or the second object. Ramakrishnan 
does not teach or suggest renaming, deleting, or moving data, or an accompanying rule directing 
an update of at least one of the contract object and the second object responsive to such events. 
Thus, claims 54-56 and 62-64 are patentable under 35 U.S.C. § 102(b) over Ramakrishnan. 
Accordingly, claims 54-56 and 62-64 are allowable. 

Referring to claim 26, the invention is directed towards a computer-implemented method 
according to claim 17, further comprising associating a second rule with the contract object, the 
second rule including a second event that can occur to the second object and a second action. 
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Referring to claim 60, the invention is directed towards a computer-implemented method 
according to claim 26, further comprising: receiving the second event; accessing the second rule 
associated with the contract object; and updating at least one of the contract object and the first 
object according to the second action responsive to the second event. 

Referring to claim 61, the invention is directed towards a computer-implemented method 
according to claim 60, wherein accessing the second rule includes selecting the second rule from 
a plurality of rules based on receiving the second event occurring to the second object. 

Referring to claim 68, the invention is directed towards computer-readable media 
according to claim 44, further comprising software to associate a second rule with the contract 
object, the second rule including a second event that can occur to the second object and a second 
action. 

Referring to claim 69, the invention is directed towards computer-readable media 
according to claim 68, further comprising: software to receive the second event; software to 
access the second rule associated with the contract object; and software to update at least one of 
the contract object and the first object according to the second action responsive to the second 
event. 

Referring to claim 70, the invention is directed towards computer-readable media 
according to claim 69, wherein the software to access the second rule includes software to select 
the second rule from a plurality of rules based on receiving the second event occurring to the 
second object. 

Taken together, claims 26, 60, 61 , and 68-70 recite associating a second rule with the 
contract object. Recall that the first rule recited in claims 17 included a first event that could 
occur to the first object. In contrast, the second rule recited in claims 26 and 68 includes a 
second event that can occur to the second object. In other words, in claims 26 and 68, there are 
at least two rules associated with the contract object: one including a first event that can occur to 
the first object, and another including a second event that can occur to the second object. In 
addition, the first rule includes a first action to be performed if the first event occurs to the first 
obj ect, and the second rule includes a second action be performed if the second event occurs to 
the second object. 
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Claims 60 and 69 recite receiving the second event for the second object. Then, in 
response to the second event occurring to the second object, either the contract object or the first 
object are updated according to the second action. 

Claims 61 and 70 recite selecting the second rule from a plurality of rules based receiving 
the second event occurring to the second object. While two rules are recited in claims 26, 60-61 
and 68-70, there can be additional rules associated with the contract object. These additional 
rules can include other types of events that can occur to either the first object or the second 
object. When the system receives notification of an event, the system selects the rule based on 
the event and the object to which the event occurred. 

In rejecting claim 26, the Examiner again cites to Ramakrishnan using a query as 
teaching a second event. As argued above, the Applicant does not believe a query is analogous 
to an event as recited in claims 26, 60-61, and 68-70. A query simply returns a dataset matching 
the query: a query does not update any data. Even if Ramakrishnan teaches that different queries 
can be run on a dataset, a query is still a passive request for data, without any update to the data. 
A query does not include a rule for updating the first object or the contract object in response to a 
change in the second object. As Ramakrishnan does not teach a first rule for updating the 
contract object or the second object, Ramakrishnan also does not teach or suggest a second rule 
for updating the contract object or the first object. 

Because Ramakrishnan does not teach of suggest a second event that can occur to a 
second object or a rule for updating the contract object or the first object after receiving the 
second event, claims 26, 60-61, and 68-70 are patentable under 35 U.S.C. § 102(b) over 
Ramakrishnan. Accordingly, claims 26, 60-61, and 68-70 are allowable. 

Referring to claim 57, the invention is directed towards a computer-implemented method 
according to claim 17, further comprising associating a third rule with the contract object, the 
third rule including a third event that can occur to the first object and a third action. 

Referring to claim 58, the invention is directed towards a computer-implemented method 
according to claim 57, further comprising: receiving the third event; accessing the third rule 
associated with the contract object; and updating at least one of the contract object and the 
second object according to the third action responsive to the third event. 
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Referring to claim 59, the invention is directed towards a computer-implemented method 
according to claim 58, wherein accessing the third rule includes selecting the third rule from a 
plurality of rules based on receiving the third event occurring to the first object. 

Referring to claim 65, the invention is directed towards computer-readable media 
according to claim 44, further comprising software to associate a third rule with the contract 
object, the third rule including a third event that can occur to the first object and the third rule 
further including a third action. 

Referring to claim 66, the invention is directed towards computer-readable media 
according to claim 65, further comprising: software to receive the third event; software to access 
the third rule associated with the contract object; and software to update at least one of the 
contract object and the second object according to the third action responsive to the third event. 

Referring to claim 67, the invention is directed towards computer-readable media 
according to claim 66, wherein the software to access the third rule includes software to select 
the third rule from a plurality of rules based on receiving the third event occurring to the first 
object. 

Claims 57-59 and 65-67 further clarify the concept of multiple rules. Claims 57 and 65 
recite a third rule including a third event that can occur to the first object. In contrast to claims 
26 and 68 where the second rule includes a second event that could occur to the second object, in 
claims 58 and 66, the first or third events can both occur to the first object, and the contract 
object or second object can be updated according to the first or third actions. Finally, claims 59 
and 67 recite that the third rule is selected from a plurality of rules based on receiving the third 
event to the first object. 

Note that in each of these cases, the appropriate rule depends on the event that is received 
and the object to which the event occurred. This point is made on page 8, lines 20-23 of the 
specification where it states that "there can be more than one rule to apply to a given contract for 
a single event. Finally, the rules to be applied to one contract can differ from the rules applied to 
another contract, even given the same event." 

For example, if the first object is a file object, the second object is a collection object, and 
the event is a delete event, the action associated with delete events can be different depending on 
whether the first object is deleted or the second object is deleted. If an event was a delete event 
to the second object (i.e., collection object) storing the first object (i.e., file object), the 
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corresponding action to this event could be to delete the first object (i.e., file object), and then 
delete the contract object. In other words, both the first object and the contract object are deleted 
in response to the second object being deleted. But deleting the first object (i.e., file object) 
could trigger a different action. Upon a deletion of a file object, the action could be to 
disassociate the contract object from the collection object, and then delete the contract object. 
But the collection object would not be deleted in response to the file object being deleted. 

Because Ramakrishnan does not teach or suggest a third event that can occur to a first 
object or a third rule for updating either the contract object or the second object, claims 57-59 
and 65-67 are patentable under 35 U.S.C. § 102(b) over Ramakrishnan. Accordingly, claims 57- 
59 and 65-67 are allowable. 

Referring to claim 28, the invention is directed towards a computer-implemented method 
according to claim 17, further comprising: storing a third locator for the contract object in the 
first object; and storing a fourth locator for the contract object in the second object. 

Referring to claim 49, the invention is directed towards computer-readable media 
according to claim 48, further comprising: software to associate the third identifier of the 
contract object with the first object; and software to associate the third identifier of the contract 
object with the second object. 

Locators to the contract object can be stored in the first object and the second object, 
making it easy to access and update appropriate contract object when the first object is changed. 
FIG. 4B of the specification shows file 1 15, collection 205, and contract 215 with their 
respective addresses in storage. As described on page 7, lines 3-9 of the specification, "[fjile 115 
has address 442, collection 205 has address 445, and contract 215 has address 448. File 115 and 
collection 205, in their lists of associated contracts, store the address of contract 215, as shown 
by entries 451 and 454, respectively. Similarly, contract 215 stores the addresses of file 1 1 5 and 
collection 205, as shown by file addresses 457 and collection address 460, respectively. By 
storing the addresses instead of object IDs, the objects can be located without referring to an 
object table." 

Similarly, an identifier to the contract object can be associated with the first object and 
the second object. For example, if the first object is deleted, the contract object can receive the 
deletion event, then the second object can be notified that the first object has been deleted and 
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the relationship (i.e., the contract object representing the relationship) between the first object 
and second object can be removed. Identifiers operate similarly to locators, but use the system to 
locate the object. FIG. 4A of the specification shows contract 215 is an entry in contract object 
table 403. As described on page 5, line 32 to page 6, line 10 of the specification, "file 1 15 has 
file ID 18, shown by file identifier 41 8. Identifier 418 is part of file object table 421, similar to 
contract object table 403, and maps file identifiers to a location in the storage where the 
identified file can be found. Similarly, collection 205 has collection ID 2B, shown by collection 
identifier 424, and collection identifier 424 is part of collection object table 427. . . Both file 115 
and collection 205 have a list of associated contracts (respectively, lists 430 and 433). These 
lists store the contract IDs of contracts that are associated with the objects. Note that both of lists 
430 and 433 include contract ID 37 (as entries 436 and 439, respectively), which identifies 
contract 215. This allows both file 1 15 and collection 205 to locate contract 215, which 
establishes the relationship between file 115 and collection 205." In other words, contract ID 37 
is stored in the list for file 115 and the list for collection 205. 

The Examiner has cited the employees entity and the departments entity as examples of 
the first and second objects, and the Works_In relationship as an example of a contract object. 
For the locators in claim 28, the Examiner cited to the primary key and foreign keys in the 
Works_In table on page 363. The Works ln table has two foreign keys: the first is a social 
security number referencing an Employees table, and the other foreign key is a department 
identifier referencing a Departments table. 

The example on page 363 of Ramakrishnan shows references to the Employee and 
Department tables using the relationship Works_In table. But this example does not show a 
reference from the Works_In table in the Employee and Department tables. If the Examiner is 
arguing that the Works_In table is the contract object of the present application, then for 
Ramakrishnan to teach claims 28 and 49, Ramakrishnan would have to teach a locator or 
identifier to the Works_In table stored in the Employee and Department tables. But 
Ramakrishnan does not teach storing an identifier or locator to the Worksjn table in the 
Employee and Department tables. As claims 28 and 49 recite an identifier of the contract object 
associated with the first and second objects, claims 28 and 49 are patentable under 35 U.S.C. 
§ 102(b) over Ramakrishnan. Accordingly, claims 28 and 49 are allowable. 
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Referring to claim 27, the invention is directed towards a computer-implemented method 
according to claim 1 7, wherein: identifying a first object includes identifying a file object; and 
identifying a second object includes identifying a collection object. 

In rejecting for claim 27, the Examiner cites to Ramakrishnan's teaching of entities in 
general as teaching a file object. But while Ramakrishnan might teach entities as objects, 
Ramakrishnan does not teach that a file can be a type of object. In fact, as Ramakrishnan is 
directed towards database entities and relationships of those entities, Ramakrishnan does not 
contemplate a file object being an object. 

The Examiner argues that the specification does not specifically define the limitation of 
"file object." In paragraph 24 on page 8 of the Office Action dated January 24, 2006, the 
Examiner says that "the instant specification describes an 'object is a "thing" represented in a 
computer' (page 3, lines 25-26). Therefore, the citation of objects from a database has been 
interpreted as a 'file object.'" 

Page 3, lines 25-27 of the specification describes an object as "a 'thing' represented in a 
computer. There is no limit on what type of 'thing' the object is. For example, a file is an 
object." The specification might not limit all objects to be file objects, but claim 27 explicitly 
does recite this feature and the specification supports an object being a file object. Thus, the 
Examiner is impermissibly broadening claim 27 by ignoring the term "file". Indeed, 
Ramakrishnan does not teach or suggest a file object, only databases and tables. 

Because Ramakrishnan does not teach or suggest using a contract object to represent a 
relationship between a file object and a collection object, claim 27 is patentable under 35 U.S.C. 
§ 102(b) over Ramakrishnan. Accordingly, claim 27 is allowable. 

Referring to claim 71, the invention is directed towards a computer-implemented method 
according to claim 17, wherein: identifying a first object includes identifying first spreadsheet 
object; and identifying a second object includes identifying a second spreadsheet object. 

Claim 71 is directed towards using a contract object to represent a relationship between a 
first spreadsheet object and a second spreadsheet object. Support for claim 71 is found on page 
1, line 31 to page 2, line 2 of the specification. A spreadsheet is an application using cells to 
store data, and allowing cells to reference one another. 
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Just as Ramakrishnan does not teach a file object, Ramakrishnan similarly does not teach 
or suggest a spreadsheet object. Thus, claim 71 is patentable under 35 U.S.C. § 102(b) over 
Ramakrishnan. Accordingly, claim 71 is allowable. 



REJECTION UNDER 35 U.S.C. § 103(a) 
Referring to claim 24, the invention is directed towards a computer-implemented method 
according to claim 17, further comprising storing a metadata for the first object in the contract 
object. 

Metadata is discussed on page 6, lines 1 1-16 of the specification. Metadata about the 
first object can be stored in the contract object to provide redundancy between the contract object 
and the first object. Page 6, lines 20-26 of the specification also notes that "storing metadata 
about the objects in contract 403 can be useful when one of the objects needs to know metadata 
about the other object. For example, collection 205 occasionally needs to know the name of file 
115 (such as when a user requests the names of all objects in collection 205). Storing the name 
of file 1 15 as metadata 412 in contract 215 saves one level of indirection in accessing file 115. If 
contract 215 does not store metadata 412, then the file system has to access contract 215, and 
then access file 1 1 5 to determine name of file 115." 

The Examiner has acknowledged that Ramakrishnan does not teach storing metadata for 
the first object in the contract object. The Examiner has cited Silberschatz as teaching metadata. 
Silberschatz teaches strategic directions in database systems. On page 773, Silberschatz teaches 
that "[information accessed from a wide-area network may be of varying quality. Quality 
relates to the timeliness, completeness, and consistency of the data. Future information systems 
must be able to assess and react to the quality of the data source. Often the source of the data 
with give clues regarding data quality. Quality-related metadata must be captured and processed 
in a way that is as transparent as possible to the user." 

While Silberschatz teaches quality-related metadata, Silberschatz does not teach storing 
metadata for a first object in a contract object as recited in claim 24. As previously discussed, 
the quality-related metadata that Silberschatz gathers refers to how timely, complete, and consist 
data is that is obtained. But this is not metadata for a first object stored in a contract object as 
claimed. It is other metadata. Also, while Siblerschatz teaches capturing quality metadata, 
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Silberschatz does not teach storing the quality metadata in a "contract object" such as the 
Works_In table of Ramakrishnan. 

Claim 24 does not recite metadata generally, but rather metadata about the first object 
stored in the contract object, allowing the contract object to directly access the stored metadata 
without having to go to the first object itself to obtain the metadata information. Neither 
Silberschatz nor Ramakrishnan teach storing such metadata about the first object in the contract 
object. 

Because neither Ramakrishnan nor Silberschatz teach or suggest storing metadata for the 
first object in the contract object, claim 24 is patentable under 35 U.S.C. § 103(a) over 
Ramakrishnan in view of Silberschatz. Accordingly, claim 24 is patentable. 

For the foregoing reasons, reconsideration and allowance of claims 17-24, 26-33, 44-46, 
48-51, and 54-71 of the application as amended is solicited. The Examiner is encouraged to 
telephone the undersigned at (503) 222-3613 if it appears that an interview would be helpful in 
advancing the case. 



MARGER JOHNSON & McCOLLOM, P.C. 
210 SW Morrison Street, Suite 400 
Portland, OR 97204 
503-222-3613 



Customer No. 45842 
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Respectfully submitted, 



MARGER JOHNSON & McCOLLOM, P.C. 




Ariel S. Rogson 
Reg. No. 43,054 



